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(57) Abstract: The invention relates to a method of controlling data packet traffic at the input of a network, whereby the traffic 
comprises N streams and/or substreams which are each associated with a priority level. N = 2, and each of the aforementioned 
packets is marked with the priority level associated with the stream or substream to which said packet belongs. The inventive method 
comprises a step employing a token bucket mechanism with N operating levels and N token buffers each containing a number of 
^ available tokens, the tokens of each of the N token buffers being used to process one of the N priority levels. Moreover, each of the 
^5 packets is accepted or refused according to whether or not it is possible for same to be attributed tokens depending on the tokens 
available at least in the token buffer which is used to process the priority level of each packet. In one particular embodiment of 
On the invention, the tokens from the N token buffers are shared between the N priority levels, and a packet with priority level i can 
O be attributed tokens from a token buffer which is associated with priority level j, said level having less priority, when there are not 
sufficient tokens available in the i priority level token buffer. 



(57) Abrege : Llnvention conceme un procede de controle d\in traffic de paquets de donnees en entree d*un reseau, le trafic com- 
prenant N flux et/ou sous-flux associes chacun a un niveau de priorite, N ^ 2, chacun des paquets etant marque avec le niveau de 
W priorite associe au flux ou sous-flux 
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abreviations" figurant au debut de chaque numiro ordinaire de 
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auquel appartient ledit paquet. Le procede comprend une etape de mise en oeuvre d'un mecanisme de seau a jetons a N niveaux de 
fonctionnement avec N memoires-tampons de jetons contenant chacune un nombre de jetons disponibles. Ies jetons de chacune des N 
memoires-tampons de jetons etant utilises pour traiter Tun des N niveaux de priori te, chacun des paquets etant accepte ou refuse selon 
quil est possible ou non de lui attribuer des jetons en fonction des jetons disponibles au moins dans la memoire-tampon de jetons 
utilisee pour trailer le niveau de priorite dudit paquet. Dans un mode de realisation particulier. Ies jetons des N memoires-tampons 
de jetons sont paitages entre les N niveaux de priorite, un paquet de niveau de priorite i pouvant se voir attribuer des jetons d'une 
memoire-tampon de jetons associee a un niveau de priorite j moins prioritaire lorsque les jetons disponibles dans la memoire-tampon 
de jetons de niveau de priorite i ne sont pas suflQsants. 
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Precede et dispositif de controle d'un trafic de paquets de donnees en entr^ 
d'lin reseau, programme d'ordinatem* et equipement r&eau correspondants. 

Le domaine de rinvention est celui des rSseaux de communication, et 
notanmient mais non exclusivement des r6seaux de tj^e IP ou equivalents. 
5 Plus pr6cis6ment, I'invention conceme un proc6d6 de contrdle d'un trafic de 

paquets de donn6es en entr6e d'un r6seau, dans le cas oil le trafic comprend une plurality 
de flux et/ou sous-flux associ6s chacun k un niveau de priority, et oil chacun des paquets 
est marqu6 avec le niveau de priority associ6 au flux ou sous-flux auquel appartient ce 
paquet. En d'autres termes, I'invention conceme un mecanisme reseau permettant 
10 d'optimiser I'^coulement d'un trafic entrant sur un r6seau. 

L'invention a de nombreuses applications, telles que par exemple le controle de 
flux multimedia (par exemple des flux MPEG), seuls ou par agregats, ou encore le 
controle d'un multiplex de flux de diff6rentes natures (par exemple un flux viddo/audio 
multiplex^ avec im flux TCP, sur un acces ADSL). 
15 On pr6sente maintenant brifevement le contexte reseau dans lequel se situe la 

pr6sente invention. 

L' augmentation des performances des ordinateurs ainsi que les debits offerts par 
les nouvelles generations de r6seaux ouvrent la voie k de nouveaux services bas6s sur les 
flux multim6dias. De fait, le nombre d'informations audiovisuelles transmises sur les 

20 r6seaux (par exemple de type IP (« Internet Protocol »)) crott sans cesse, et les 

algorithmes de compression (par exemple de type MPEG (« Moving Picture Experts 
Group »)) s'am61iorent, offrant une quality meilleure avec des debits plus faibles. 
Cependant, aujourd'hui le niveau de qualite n'est pas toujours acceptable. Si chaque 
maillon de la chatne a les capacit^s intiins&ques pour foumir cette quality, leur mise bout 

25 h bout et le partage des ressources r6seau IP par de nombreux usagers aboutissent parfois 

h des r6sultats m6diocres. 

D'une maniere gen6rale, la transmission d'informations dans un rdseau IP 
s'appuie sur la couche transport pour un controle de la quality entre la source et les 
r6cepteurs. Cette couche, situ6e entre le routage et les applications, est realisde 

30 traditioimellement par le protocole TCP (« Transmission Control Protocol »). D'un point 

de vue application, TCP se charge de retransmettre les informations perdues ou mal 
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regues, par un controle au niveau de la session. D'un point de vue r6seau, certains 
param&tres du protocole permettent de d6celer des possibles congestions, et d' adapter le 
debit de la source aux contraintes du r6seau. L'objectif est alors de linniter le d6bit si le 
r6seau ne peut pas tout 6couler, et d'6viter d'envoyer des paquets qui seront perdus. De 
5 nombreuses Etudes cherchent aujourd'hui k appliquer des mdcanismes 6quivalents aux 

flux vid6o, avec la contrainte temps reel d'une adaptation dynamique des codeurs au 
debit disponible. 

Mais en raison du temps important de reaction entre un ou plusieurs clients et la 
source video, les protocoles temps r6el et audiovisuels ne font actuellement que pea de 

10 traitements, et se limitent principalement au marquage du temps d^emdssion et k 

Tencapsulation des paquets de Tapplication pour leur routage dans la couche IP (par 
exemple RTP/UDP), k charge des applications de se d6brouiller avec les donn^es re9ues. 

L'evolution des r^seaux offre la possibilite de gerer la « qualit6 de service » 
(QoS) dans les routeurs. Or, il est pertinent de remarquer que c'est le lieu ou se 

15 produisent la plupart des pertes des reseaux IP, et des m6canismes sont mis en oeuvre k 

ce niveau pour traiter selectivement les differents flux en vue d* assurer au mieux <Jes 
objectifs de quality. Les moyens d6ploy6s pour am^liorer la quality des flux transmis 
sont Tobjet des travaux des groupes « IntServ » (pour « integrated services », c*est-^-dire 
« integration de services ») et « DiffServ » (pour « differentiated services », c*est-&-dire 

20 « services diff6renci6s ») k TIETF (Intemet Ingineering Task Force) : 

- « IntServ » dSfinit des moyens pour r6server une ressource en d6bit garantie 
entre deux noeuds d'un r6seau ; 

- « DiffServ » d6finit des moyens pour contrSler dynamiquement le d6bit 
d'agr6gats de flux en fonction de la charge du reseau. 

25 En comparaison avec les solutions de bout en bout (analogues k TCP) les 

solutions localisSes dans les routeurs ont plusieurs avantages : 

- elles s'affranchissent de toute contrainte de session ; 

- elles sont aussi adapt6es au temps r6el, car leur action dans les routeurs est 
immediate sans necessiter de retour d' informations en provenance des 

30 usagers ; 
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- eUes sont done natureUement adaptdes k la diffusion selective (« multicast »), 
car ind^pendantes du nombre d'usagers alimentds par le flux ct 
ind6pendantes de rapports en provenance d'un nombre variable d'usagers. 

Les traitements dans les routeiurs s'appuient sur une distinction des paquets 
arrivant dans les routeurs supportant des m6canismes de « quaUt6 de service » (QoS, 
pour « Quality of Service »). 

Cette distinction existe natureUement dans les flux MPEG, car la compression 
des flux video MPEG aboutit k une suite de donn6es de natures diff6rentes et non 
ind^pendantes. On distingue trois types d'images : I, P et B. Les images de type I (Intra), 
sont chacune cod6es sans faire reference k une autre image, la compression 6tant limitfe 
k la reduction des redondances spatiales au sein de chaque image. Pour optimiser la 
quantit6 d' informations transmises, les codeurs MPEG exploitent le fait que deux 
images cons6cutives sont peu diff6rentes en gen6ral. Une detection de mouvement ne 
considfere que la partie qui vient de changer par rapport k I'image pr6c6dente pour 
obtenir une information de taille r6duite cod6e dans une image de type P (Pr6dite). 
D'autres moyens permettent d'obtenir une information encore plus r^uite en interpolant 
les mouvements entre deux images de type I ou P ; ces images sont alors de type B 
(Bidirectionnelle). 

La taille des images P est beaucoup plus petite en g€n6ral que celle des images I, 
et un codage avec peu d'images I permet d'obtenir, k d6bit Equivalent, une quality de 
d6codage bien sup6rieure. Dans ces conditions, la perte d'une image n'est pas 
6quivalente en fonction de la nature de I'information qu'elle contient. Cette structure de 
I'information doit conduire k consid^rer I'importance ou le poids de chaque information 
dans son traitement par le r6seau. 

Deux raisons justifient la conservation d'images I : 

- la re-synchronisation pfitiodique du flux en cas de pertes ; 

- tout changement de scfene car il n'est plus possible de s'appuyer sur les 
images precedentes pour un codage de mouvement 

Une autre maniere de consid6rer ce poids de I'information est la ddcoupe d'un 
flux MPEG4 en plusieurs niveaux hierarchiques pour obtenir une quality variable en 
fonction du contenu global regu par I'usager. Un niveau hi6rarchique N doit s'appuyer 
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sur la pr6sence des N-1 niveaux inferieurs pour apporter un complement de qualite. Un 
cas 616meiitaire est de consid6rer ime vid6o constituee d*im flux de base (contenant des 
images I et P) et d'un flux de rehaussement (contenant des images P et B). Pour ce cas 
616mentaire, le flux de base dans sa globalit6 est consid6r6 plus prioritaire que le flux de 
rehaussement. 

La distinction de nature des images ou des flux dans le trafic MPEG est h 
exploiter dans les routevurs « DiffServ » pour traiter s61ectivement les diff6rentes 
informations d'un flux vid6o : 

- soit par un marquage du champs TOS (« type of service », c*est-i-dire « type 
de service ») ou DSCP (« Differentiated Services Code Point », c*est-a-dire 
« valeur de marquage pour services diff6renci6s ») des paquets par le serveur 
vid6o, 

- soit par une classification effectu6e par le routeur, ce qui aboutit 6galement h 
un marquage des paquets IP. 

Dans le present document, on considfere que le marquage des paquets est 
possible dans tous les cas. Les moyens de r6aliser ce marquage sont consid6res comme 
bien coimus de I'honune du metier. lis ne sont done pas discut6s en detail. 

Quand une situation de congestion apparait dans un routeur, les paquets regus 
sont 61imin6s en fonction de la charge et de leur niveau de priority. 

Une caract6ristique importante des donndes contenus dans ces paquets est leur 
variation importante en fonction du contenu de la scfene. Or, les informations les plus 
critiques pour la restitution k Tusager sont contenues dans les rafales les plus 
importantes, et le problfeme principal des r6seaux IP de type « Best effort » (c'est-k-dire 
sans garantie) est leur difficult6 h. laisser passer les rafales en cas de congestion. 

De ce fait, le simple marquage des flux el6mentaires d'un flux MPEG n'est pas 
sufflsant pour leur traitement optimal. En effet, les m^canismes « DiffServ » usuels sont 
pr6vus pour accepter des rafales que Ton trouve habituellement dans les reseaux DP, avec 
les applications qui sont majoritaires aujourd'hui : le transfert d'URL (« Uniform 
Resource Locator ») pour les applications WEB et les transferts de fichiers par FTP 
(« File Transport Protocol »). Toutes ces applications exploitent le protocole TCP dont 
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les mecanismes ont fait Tobjet de nombreuses 6tudes afin d'obtenir une montee en 
charge progressive, et une adaptation du d^bit en fonction de la charge du r6seau. 

Or, les flux vid6o remettent en cause ce fonctionnement car leur comportement 
est qualifi^ d'agressif, dans la mesure od ils ignorent g6n6ralement I'dtat et la charge du 
5 r^seau. De plus, la plupart des m^canismes introduits dans les r6seaux IP ont tons pour 

objectif le lissage des flux pour favoriser un bon ecoulement du trafic. Paradoxalement, 
les codeurs foumissent une quality meilleure quand ils produisent des flux k d6bit 
variable, qui sont les plus maltrait6s dans les reseaux IP. 

L' introduction de flux video dans le reseau IP se heurte done k trois 
10 contradictions : 

- augmenter la qualite des codages, conduit pour un d6bit moyen defini, k 
produire des rafales de paquets quand la sequence codee I'exige ; 

- les reseaux d'acces offrent une bande passante maximale limitee (y compris 
en ADSL (« Asymetric Digital Subscriber Line ») car les applications sont 

15 tent6es d*exploiter un d6bit moyen proche du maximum pour procurer la 

meilleure quality aux usagers ; 

- les rafales sont les informations les plus importantes car elles correspondent k 
un changement de sc^ne ou au moins k un changement important du contenu 
de rimage. Bien souvent, ces images sont du type I (Intra) dont la perte est 

20 tihs critique, car il devient impossible de reproduire les images suivantes, 

mSme si ces demi^res sont correctement revues. 
On pr6sente maintenant les techniques connues de conditionnement de trafic 
visant k r6duire les congestions dans les reseaux. 

On notera tout d'abord que les travaux sur I'application de la mise en forme pour 
25 les flux MPEG dans les r6seaux DP en se basant sur UDP et RTP comme protocoles de 

transport sont tres rares. La majorite des travaux concernent les r6seaux ATM 
(« Asynchronous Transfer Mode ») et T utilisation de TCP comme protocole de 
transport. 

Les m6canismes de mise en forme et de conditionnement de trafic sont utilises 
30 dans les reseaux IP k « quality de service » (QoS). On pent notamment se reporter au 

document « Traffic Shaping for MPEG video transmission over next generation 
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internet » (lissage de trafic pour la transmission de video MPEG sur T internet de 
prochaine g6n6ration), M.F Alan, M. Atiquzzaman, M. A. Karim. Dans ce document, le 
lissage de trafic (TS) est utilise pour assurer la conformite des flux MPEG au TSPEC 
(« Traffic Specifier » c'est-^-dire « sp6cification de trafic ») n6cessaire k la reservation 
S de ressources dans les reseaux « IntServ ». Pour les rdseaux « DiffServ », le traitement 

se fait par agr6gat de fiux et done sans trop se soucier des applications. Les algorithmes 
de lissage de trafic (TS) sont par contre largement utilises au niveau du codage dans le 
but de contrdler le d6bit des codeurs. Ceci reste insuffisant pour maitriser les flux au 
niveau reseau. 

10 L' utilisation de la mise en forme, par lissage de trafic (TS, pour « Traffic 

Shaping ») ou controle des rfegles de trafic (ou TP, pour « Traffic Policing »), pour 
r^duire la congestion dans le r6seau peut ameliorer d'une maniere significative le niveau 
de « qualit6 de service » (QoS) que le reseau est capable de delivrer aux applications. 

Le lissage (TS) lisse les rafales en « bufferisant » (c'est-^-dire en mettant en 

15 memoire-tarapon) les paquets concemes par I'exc^s de rafales dans les equipements de 

firontifere du reseau. II peut reduire la congestion k des niveaux acceptables, surtout que 
les algorithmes d'ordonnancement (« scheduler ») tels que CBQ (« Class Based 
Queuing » c'est-^-dire « gestion de flies d'attente bashes par classes de services ») ou 
bien PQ (« Priority Queuing » c'est-^-dire « gestion de files d*attentes par prioritSs ») ne 

20 sont pas capables de le faire. Utilises seuls, ces m^canismes propagent les rafales dans le 

r6seau. 

Conrnie le lissage (TS), le contr51e des regies de trafic (TP) limite le d6bit du 
trafic au d6bit configure. Mais au lieu de « bufferiser » les paquets comme le lissage 
(TS), les paquets non-conformes sont soit rejet6s, soit remarqu6s pour diminuer leurs 

25 priorites. Le contrSle des r&gles de trafic (TP) ne lisse pas par consequent le trafic mais 

il n'introduit pas de d61ai de « bufferisation » non plus. 

Dans la majorite des architectures qui supportent la « qualite de service » (QoS), 
un contrat de service existe entre le foumisseur du service r6seau (NSP, pour « Network 
Service Provider ») et le foumisseur de T application (ASP, pour « Application Service 

30 Provider »). Dans les r6seaux ATM, ce contrat est appel6 « Contrat de trafic ». Dans les 

r6seaux « DiffServ », les aspects de contractualisation sont traites dans le SLA 
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(« Service Level Agreement ») et plus pr6cis6ment dans le SLS (« Service Level 
Specification »). 

On connait 6galement le document suivant : RFC2475. « An Architecture for 
Differentiated Services » (une architecture pour des services diff6renci6s), D6cembre 
1998. n precise que les sources de trafic peuvent assurer les tiches de classification et de 
conditionnement de trafic. En effet, le trafic peut 6tre marqu6 avant de quitter le 
domaine source. Ce marquage initial est appel6 « Initial Marking » ou « Pre-marking ». 
L'avantage du marquage initial est que les preferences et les besoins des applications 
peuvent gtre mieux pris en compte pour decider quels paquets doivent recevoir un 
meilleur traitement dans le reseau. 

La prevention centre la surcharge d'une classe de service donnee n'est pas une 
tache facile dans les r6seaux « DiffServ ». En plus, en cas de surcharge dans une classe 
de service, il faut noter que tons les flux de cette classe de service souffrent d'une 
degradation de la « qualite de service » (QoS). 

En plus, plusieurs mecanismes utiUses dans la mise en oeuvre de « DiffServ » 
fonctionnent d'une fa^on moins efficace en presence des rafales. Le mecanisme RED 
(« Random Early Drop »), par exemple, est plus efficace lorsqu'U est applique k un 
trafic lisse, sinon ce sont les flux lisses qui sont penalises alors que les flux en rafales ne 
subissent pas une amelioration significative. 

Les flux MPEG sont caracterises par le fait qu'ils presentent des rafales (nature 
« bursty ») et par leur sensibilite aux pertes de paquets. Ces pertes causentune 
degradation de la quaUte subjective, mais il est trfes difficile de prevoir le niveau de cette 
degradation suite k des pertes. Cette degradation est fortement Uee k la nature des 
informations transportees par les paquets perdus. Les mecanismes de correction 
d'erreurs sont utilises lots du decodage pour palier aux pertes. 

Gerer les flux MPEG dans le reseau, ou mSme dans les routeurs d'extremite (ER, 
pour « Edge Router »), est une tache compliquee. Le foumisseur du service reseau 
(NSP) n'est pas obUge de tiraiter differemment les flux MPEG. En plus, I'agregat de 
trafic resultant de plusieurs flux audio-visuels est generalement difficile k decrire : 

- le processus d'arrivee de paquets est auto-similaire ; 

- grande variation des donnees transportees par les paquets ; 
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- la dynamique des protocoles, 

Une solution consiste h marquer les paquets et k leur attribuer le niveau de 
« qualite de service » (QoS) approprie avant qu'ils quittent le domaine du foumisseur de 
service sur Internet (ISP, pour « Internet Service Provider »). La passerelle d'acc&s au 
m6dia (MAG, pour « Media Access Gateway ») est par exemple responsable de cette 
tache. Cette passerelle MAG gfere le trafic selon le SLS specific. Cette approche facilite 
la negociation de SLA/SLS pour les services en mode continu (« Streaming ») et impose 
au client un profil de trafic bien particulier. 

Parmi les techniques actuelles, la plus repandue pour controler le trafic est le 
mecanisme WRED (« Weighted Random Early Drop ») qui consiste en une perte de 
paquets aleatoire et differente en fonction du marquage des paquets. Ce mecanisme se 
base sur un taux de remplissage moyen de la file d'attente d*6mission sur un lien d'un 
r6seau. Mais cette technique introduit un caractere aleatoire des rejets de paquets, et le 
taux de remplissage de la file d'attente n'est pas optimis6e. Selon les tailles des rafales et 
leur frequence, ces rejets peuvent se produire pour un remplissage faible ou un 
remplissage tres 61eve de la file d'attente. Ce qui conduit d'une part h une sous 
utilisation de la file d'attente, et d'autre part k la reservation de taille m6moire 
cons6quente pour la realisation de cette file. Ce probleme existe pour tout type 
d' application, et il est encore plus r6el pour les fiux audiovisuels en raison de leurs 
rafales importantes. 

Pour d6tailler ce point, il est fondamental de remarquer tout d'abord que les 
rafales des flux vid6o sont impr6visibles, autant en taille qu'en dur6e, tout en 
garantissant un d6bit moyen sur une p6riode de Tordre d'une seconde. Cette fenStre de 
calcul du d6bit moyen est beaucoup trop grande pour obtenir des tailles raisonnables des 
files d'attente associees. De fait, les routeurs reagissent en calculant les moyennes de 
remplissage sur une dizaine de paquets re9us, alors que certaines rafales peuvent 
largement d^passer les 20 paquets. 

Ainsi, une succession de rafales pent aboutir k des rejets par saturation de la 
capacite de la file d'attente, inhibant le fonctionnement normal du mecanisme. A 
r oppose, quand un trafic faible survient apres une suite de rafales, la valeur moyenne 
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peut rester temporairement anonnalement 61ev6e et des paquets sont rejet6s alors que la 
file est pratiquement vide. 

Le ni6canisme WRED ii*est done pas adapts au contrSle de flux caract6rises par 

une valeur moyenne sur une dui^ fixe. 

L'invention a notamment pour objectif de palliea: ces inconv6nieiits de l'6tat de la 
technique et offrir une solution optimale en cas de congestion du r6seau. 

Plus pr6cis6ment, I'un des objectif s de la pr6sente invention est de foumir un 
procede et un dispositif de contrdle de trafic permettant de contrdler des rafales et de 
lisser le trafic sur un ensemble de flux et/ou sous-flux associ6s k des niveaux de 
piiorit^s. 

En d'autres tennes, un objectif de la presente invention est de foumir un proc6d6 
et un dispositif de contrSle de trafic permettant de proteger les informations importantes 
des rafales, afin d'apporter une solution h. I'antinomie entre 1' optimisation d'un flux (par 
exemple un flux vid6o) contenant des rafales et le lissage des rafales pour un transport 

de quality dans le r€seau. 

L'invention a 6galement pour objectif de foumir de tels proc6d6 et dispositif qui 
soient simples k mettre en oeuvre et peu coflteux. 

Un autre objectif de l'invention est de foumir de tels proc6d€ et dispositif 
permettant de proposer efficacement des contrats de trafic (SLA/SLS) entre op6rateurs 
r6seau et foumisseurs de services. 

Ces diff^rents objectifs, ainsi que d'autres qui apparattront par la suite, sont 
atteints selon l'invention h I'aide d'un proc6d6 de contrdle d'un trafic de paquets de 
donn6es en entr6e d'un r6seau, le trafic comprenant N flux et/ou sous-flux associ6s 
chacun k un niveau de priorit6, N ^ 2, chacun des paquets 6tant marqu6 avec le niveau 
de priorit6 associd au flux ou sous-flux auquel appartient ledit paquet, 
ledit proc6de comprenant une 6tape de nrise en oeuvre d'un m6canisme de seau k jetons h 
N niveaux de fonctionnement avec N m6moires-tampons de jetons contenant chacune un 
nombre de jetons disponibles, les jetons de chacune des N memoires-tampons de jetons 
etant utilises pour traiter I'un des N niveaux de priorite, chacun des paquets 6tant 
accept6 ou refus6 selon qu'il est possible ou non de lui attribuer des jetons en fonction 
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des jetons disponibles au moins dans la m£moire-tampon de jetons utilis6e pour trailer le 
niveau de priorite dudit paquet 

Le principe g6n6ral de Tinvention consiste done k utiliser un seau k jetons multi- 
niveau (MLTB, pour « Multi Layer Token Bucket ») pour rejeter les paquets en dehors 
5 d'un profil requis et caract6ris6 par les N niveaux de fonctionnement du seau k jetons 

multi-niveau. Chaque paquet subit un traitement selon un marquage correspondant k son 
niveau de priority. Les paquets accept6s sont places dans une file d'attente. 

Le seau k jetons multi-niveau permet de traiter selectivement et conjointement 
plusieurs niveaux de priorit6s de flux. D est bien adapt6 k la caracterisation du trafic 

10 entre la taille des rafales en entree et recoulement du trafic en sortie. On sait qu'en cas 

de congestion du reseau, il est illusoire de chercher de la bande passante disponible. Le 
reglage des parametres du seau k jetons multi-niveau assure une relation entre les 
niveaux de priority pour equilibrer les contraintes de fonctionnement entre les debits par 
niveaux de priorite et les rafales acceptables par le seau k jeton selon les contraintes des 

15 applications transportees. La caracterisation des paramfetres des N jeux de parametres du 

seau a jetons niulti-niveau permet de nombreuses solution et pent s'adapter k peu pxhs k 
tons les cas de fonctionnement : 

- un cas extrSme est le comportement avec N jeux de parametres ind6pendants 
agissant conune des seaux k jetons ind^pendants ; 

20 - un autre cas extrSme est la possibility pour le niveau le plus prioritaire de 

prendre tons les jetons et d'aboutir k une rejet des paquets de tons les autres 
niveaux ; 

- entre ces deux extremes, toutes les configurations sont possibles, autorisant 
plus ou moins de rafales ou plus ou moins de debit r6serv6 par niveau. 

25 L' invention permet done de traiter des rafales sur les niveaux les plus 

prioritaires, du fait qu'il existe pour chaque niveau de priority une reserve disponible 
pour pr^venir toute arrivfe soudaine d'un ensemble de donnees qui ne doivent pas etre 
rejetees. 

On rappelle qu'un seau k jeton habituel ne possfede qu'un seul niveau de 
30 fonctionnement (il dispose d'un unique jeu de parametres) et traite done tons les paquets 
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indistinctement. En cas de congestion du r^seau, les paquets sont done rejet^s 
independamment de leur niveau de priorite. 

On notera que la pr6sente invention est totalement compatible avec les flux IP 
« unicast » (h destinataire unique) et « multicast » (diffuse selectivement). 
S On notera 6galement que la pr6sente invention permet de transmettre dans une 

m@me classe de service plusieurs groupes de flux avec des priorit6s differentes. En 
particulier, Tinvention permet de foumir un traitement adapts ^ un ou un groupe de flux 
vid6o (IPB ou hi6rarchique) conform6ment k un profil de trafic contractualis6 (SLS) par 
des valeurs caract6ristiques de type seau k jeton. En effet, les paramfetres facilement 

10 mesurables et adaptables d*un seau k jetons multi-niveau (MLTB) sont un moyen 

efficace de proposer des contrats de trafic (SLA/SLS) entre op^rateurs r6seau et 
foumisseurs de services. La presence d' informations prioritaires conduit k la 
sp6cification de ce seau. Les multiples declinaisons de ce seau sont un moyen d'offrir 
des classes de services adapt^es aux exigences des clients. Quelles que soient les 

15 applications, le profil de trafic fait intervenir les principaux Elements de caracterisation 

d'un flux dans un r^seau : le debit et le delai. L'invention est done un moyen de d^finir 
un contrat avec un compromis n6goci6 entre le d6bit, la taille des rafales, et le d61ai de 
transmission. 

Dans une premiere application avantageuse de Tinvention, le trafic comprend N 
20 sous-flux correspondant chacun k un des N niveaux hi6rarchiques d'un flux hi6rarchique 

ou d'un agr6gat de flux hi^rarchiques. 

n s'agit par exemple d*un flux hi^rarchique audio/viddo comprenant les sous- 
flux suivants : un sous-flux audio, un sous-flux video de base et un sous-flux vid6o de 
r6haussement. 

25 Dans une deuxi&me application avantageuse de l'invention, le trafic comprend N 

sous-flux correspondant chacun k un des N types d'images d'un flux multim6dia ou d'un 

agrdgat de flux multimedia. 

II s'agit par exemple d'un flux vid6o MPEG comprenant trois sous-flux 

correspondant aux trois types d'images I, P et B. 
30 Dans une troisifeme application avantageuse de l'invention, le trafic comprend N 

flux correspondant chacun k un des flux d'un multiplex d'au moins deux flux. 
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n s'agit par exemple d'un flux vid6o/audio multiplex^ avec un flux TCP, sur un 
accfes ADSL. 

Avantageusement, le trafic comprend N flux et/ou sous-flux appartenant h une 

m&me classe de service. 

Ainsi, rinvention, grSce au seau ^ jetons multi-niveau, permet de transmettre 
dans une m6me classe de service plusieurs flux et/ou sous-flux avec des priorit6s 
differentes. On peut distinguer plusieurs classes de service, telles que par exemple la 
classe « streaming » (contenant des flux audio et vid6o, la classe « TCP prioritaire », la 
classe « Best Effort de r6seau IP », ...) et utiliser un seau h jeton multi-niveau pour 
chaque classe. Chaque classe de service peut 8tre d^finie par marquage des paquets, par 
I'adresse IP source ou destination des paquets, par le protocole utilis6 pour les paquets, 
etc. 

Preferentiellement, les paquets refuses sont jetes. 

Les paquets refus6s sont ceux qui ne sont pas conf ormes au profil de trafic ddfini 
par les paramfetres des N niveaux de fonctionnement du seau h. jetons muM-mveau. 

Une autre option, moins performante mais qui rentre n^anmoins dans le cadre de 
la pr^sente invention, est de transmettre les paquets refuses aprfes les avoir h. nouveau 
marques avec un niveau de priority plus faible. Cette option pr^sente toutefois 
l'inconv6nient d'augmenter la probability de rejet de paquets dans les noeuds 
congestionn6s du r6seau. 

Avantageusement, le r^seau est de type IP ou ^uivalent 

Selon une carac^ristique avantageuse, chacun des N niveaux de fonctionnement 
du m^canisme de seau h jetons est g6t6 par un rdgulateur bjCrj, bm^, i G {1 a N}, avec : 
rj le ddbit nominal du r6gulateur ; 

bmj la taille maximale de la m€moire-tampon de jetons du r€gulateur ; 

bi(t) la valeur instantanfe du remplissage de la m6moire-tampon de jetons du 

regulateur. 

De fagon pr6f6rentielle, les jetons des N memoires-tampons de jetons sont 
partages entre les N niveaux de priorit6, un paquet de niveau de priorite i pouvant se voir 
attribuer des jetons d'une memoire-tampon de jetons associee k un niveau de priority j 
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moins prioritaire lorsque les jetons disponibles dans la m6moire-tainpoii de jetons de 
niveau de priority i ne sont pas suffisants. 

De cette fagon, on favorise les rafales des niveaux les plus prioritaixes. 

Avantageusement, pour chaque niveau de priority hormis le niveau de priority le 
5 plus prioritaire, on garantit une quantity de jetons r6serv6s exclusivement aux paquets 

possSdant ledit niveau de priority. 

Ainsi, on garantit une ressource minimum pour chaque niveau de priority, sans 
exclure un usage partiellement partage des ressources (c'est-i-dire des jetons des 
differents niveaux de fonctionnement du seau ^jetons multi-niveau). 
10 Dans un premier mode de realisation particulier de Tinvention, Tattribution de 

jetons ^ un paquet de niveau de priority i est effectuee selon un mode discontinu par 
paquet et consiste h attribuer : 

soit des jetons disponibles dans la memoire-tampon de jetons de niveau de 

priorite i ; 

IS - soit des jetons disponibles dans une memoire-tampon de jetons de niveau de 

priority j moins prioritaire, lorsque les jetons disponibles dans la memoire- 
tampon de jetons de niveau de priority i ne sont pas suffisants. 
Ainsi, dans le mode discontinu, un paquet ne pent se servir des ressources 
(jetons) que d'un seul niveau de fonctionnement du seau ^jetons multi-niveau. 
20 Dans un second mode de realisation particulier de Tinvention, Tattribution de 

jetons k un paquet de niveau de priorit6 i est effectu6e selon un mode continu par bit et 
consiste k attribuer : 

des jetons disponibles dans la m6moire-tampon de jetons de niveau de priority i ; 
et en complement des jetons disponibles dans au moins une m6moire-tampon de 
25 jetons de niveau de priorit6 j moins prioritaire, lorsque les jetons disponibles 

dans la memoire-tampon de jetons de niveau de priority i ne sont pas suffisants. 
En d'autres termes, dans le mode continu, un paquet peut se servir des ressources 
(jetons) de plusieurs niveaux de fonctioimement du seau a jetons multi-niveau k la fois. 

De fa9on avantageuse, les paquets acceptes par le mecanisme de seau k jetons k 
30 N niveaux de fonctionnement sont plac6s dans une file d'attente. Ledit procdde 

comprend en outre une 6tape de mise en oeuvre d'un mdcanisme de seau k jetons k un 



wo 2004/095783 



PCT/FR2004/000955 



14 

seul niveau de fonctionnement avec une unique m6moiie-tampon de jetons, de fa9on k 
prendre les paquets contenus dans la file d'attente et les envoy er sur le r€seau en 
executant un lissage du trafic par limitation du d6bit instantan6 k une valeur acceptable 
par le r6seau. 

Le seau k jetons k un seul niveau de fonctionnement (TBTS, pour « Token 
Bucket Traffic Shaper ») permet done de limiter les debits crStes 6mis par T^quipement 
reseau supportant I'invention. n realise une temporisation des rafales quand elles 
d6passent le d6bit 1616x6 dans le r6seau. 

On utilise par exemple une zone memoire, dont I'entree est geree par le seau 
multi-niveau (controle des rafales) et dont la sortie est geree par le seau k un seul niveau 
(lissage de trafic). 

L'invention conceme 6galement un programme d'ordinateur comprenant des 
instructions de code de programme pour I'execution des etapes du precede tel que 
pr6cit6, lorsque ledit programme est execute sur un ordinateur. 

L'invention conceme aussi un dispositif de controle d'un trafic de paquets de 
donn6es en entree d'un reseau, le trafic comprenant N flux et/ou sous-flux associes 
chacun k un niveau de priority, N ^ 2, chacun des paquets 6tant marqu6 avec le niveau 
de priority associ6 au flux ou sous-flux auquel appartient ledit paquet, 

ledit dispositif comprenant des moyens de mise en oeuvre d'un mficanisme- de 
seau k jetons k N niveaux de fonctionnement avec N m6moires-tampons de jetons 
contenant chacune un nombre de jetons disponibles, les jetons de chacune des N 
m6moires-tampons de jetons 6tant utilis6s pour traiter I'un des N niveaux de priority, 
chacun des paquets 6tant accept6 ou refus6 selon qu'il est possible ou non de lui 
attribuer des jetons en fonction des jetons disponibles au moins dans la m6moire-tampon 
de jetons utilis6e pour traiter le niveau de priorit6 dudit paquet. 

De fa9on preffirentielle, ledit proc6d6 comprend des moyens de partage des 
jetons des N m6moires-tampons de jetons entre les N niveaux de priorit6, un paquet de 
niveau de priorite i pouvant se voir attribuer des jetons d'une m6moire-tampon de jetons 
associ^e k un niveau de priority j moins prioritaire lorsque les jetons disponibles dans la 
m6moire-tampon de jetons de niveau de priority i ne sont pas suffisants. 
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Avantageusement, pour chaque niveau de priorite honnis le niveau de priority le 
plus prioritaire, lesdits moyens de partage comprennent des moyens de garantie d'une 
quantity de jetons r6serv6s exclusivement aux paquets possedant ledit niveau de priority. 

L'invention conceme encore un 6quipement r6seau comprenant un dispositif de 
contr51e tel que pr6cit6, ledit 6quipement r6seau appartenant au groupe comprenant : 

des 6quipements r6seau situes entre un r6seau d'un foumisseur d' application ou 
de service et un reseau d'un foumisseur d'un service r^seau, constituant ledit 
r6seau en entr6e duquel est effectu6 le contrdle d'un trafic de paquets de 
donn^es ; 

des routeurs compris dans des noeuds d'un r6seau d'un foumisseur d'un service 
r6seau, constituant ledit reseau en entree duquel est effectue le controle d'un 
trafic de paquets de donn6es 

D'autres caracteristiques et avantages de I'invention apparaitront a la lecture de 
la description suivante d'un mode de realisation preferentiel de I'invention, donne a titre 
d'exemple indicatif et non limitatif, et des dessins annexes, dans lesquels : 

la figure 1 pr6sente un exemple d' architecture de r6seaux dans laquelle pent Stre 
mis en oeuvre le proc6d6 de contrdle de trafic selon I'invention ; 
la figure 2 illustre un mode de realisation particulier du proced6 selon 
I'invention, mettant en ceuvre deux fonctions, bas6es sur 1' utilisation 
respectivement d'un seau h, jetons multi-niveau et un seau k jetons k niveau 
unique ; 

la figure 3 illustre un r6gulateur g6rant un niveau de fonctionnement du seau k 
jetons multi-niveau illustr6 sur la figure 2, ainsi que I'utilisation dans ce 
r6gulateur d'un parametre Kj garantissant un nrinimum de ressource pour le 
niveau de priorit6 associ6 k ce r^gulateur ; 

la figure 4 illustre un exemple d' attribution de jetons dans le cas oil le 
fonctionnement du seau k jetons multi-niveau est d6crit avec des memoires- 
tampons (buffers) independantes ; 

la figure 5 illustre un exemple d' attribution de jetons dans le cas oil le 
fonctionnement du seau k jetons multi-niveau est decrit avec des mdmoires- 
tampons (buffers) corr61ees. 
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L'invention conceme done un proc6d6 de contrdle d'un trafic de paquets de 
donn6es en entree d'un rdseau. Le trafic est du type comprenant N flux et/ou sous-flux 
associ6s chacun k un niveau de priority, avec N ^ 2. Chacun des paquets est inarqu6 avec 
le niveau de priority associe au flux ou sous-flux auquel 11 appartient 

A title d'exemple, Tinvention permet de transmettre en priorit6 les informations 
essentielles d'un flux vid6o, ou de plusieurs flux vid6o regroup6s dans un agr^gat Selon 
la nature du flux, cette distinction est par exemple possible soit par les images de type 
IBP (voir d6finition ci-dessus), soit par les n couches d'un flux hi6rarchique. Si dans le 
premier cas le debit moyen des images I reste faible devant le d6bit global, dans le 
second cas Tinformation la plus importante et h proteger au maximum est d6finie par la 
fraction du d6bit global occup6 par la couche de base, et pouvant repr^senter jusqu'a 
50% du flux. En general, la couche de base est la seule k contenir les informations de 
r6f6rences contenues dans les images I. 

Dans un agr^gat, toutes les donnees de mSme niveau de priorite subissent le 
meme traitement. Par exemple, tous les flux de base ou toutes les images I sont traites 
comme un seul flux de d6bit plus important qu'une vid6o seule. 

On pr^sente maintenant, en relation avec la figure 1, un exemple d' architecture 
de reseaux dans laquelle pent 8tre mis en oeuvre le proc6de de contrdle de trafic selon 
rinvention. 

Dans cet exemple, on considfere le cas de foumisseurs de service (ISP, pour 
« Internet Service provider ») offrant un service de transmission de vid6o en mode 
continu (« streaming »). 

L'exemple d'architecture (simplifi6e) illustr^e sur la figure 1 comprend : 

- un r6seau IP de type «DiffServ » 1, g6r6 par un op6rateur r^seau (aussi 
appel6 fournisseur du service reseau, ou NSP (pour « Network service 
Provider »)) et comprenant une plurality de routeurs 2^ k 2^ compris dans des 
nc3euds du reseau IP ; 

- deux r6seaux de foumisseurs de service « streaming » 3 et 4, Tun comprenant 
deux serveurs 5 et 6, et 1' autre un serveur 7. Chaque r€seau de foumisseurs de 
service 3, 4 comprend en outre un equipement d'extremite 8, 9 connecte k 
Tun des routeurs du r6seau IP, appele routeur d'extremite (« edge routeur ») 
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2i, qui est charg6 d'envoyer les donndes d'un serveur vers une artfere 
principale d'un coeur de r&eau IP ; 

- deux tenninaux clients 10 et 1 1, chacun connect^ au r6seau IP 1 par exemple 
via un lien ADSL 12, 13. 

On suppose qu'U existe deux contrats de trafic (symbolisms par les fldches 
r6f6renc€es SLAl et SLA2 respectivement sur la figure 1) : I'un entre I'opfirateur du 
rdseau IP 1 et le foumisseur de service dont le r6seau est r6f6renc6 3, et Tautre entre 
roperateur du r^seau IP 1 et le foumisseur de service dont le r6seau est reference 4. 

Le procede selon T invention est mis en oeuvre dans un equipement reseau 
formant un conditionneur de trafic pour r entree dans le r6seau IP L Get equipement 
reseau peut gtre situe entre le r6seau du foumisseur du service 3, 4 et le reseau IP 1 : 

- soit dans Tun des equipements d'extr6mite 8, 9 des reseaux de foumisseurs 
de service 3 et 4 ; 

- soit dans le routeur d'extreniit6 2^ du r6seau IP 1 . 

L'6quipement reseau implementant le proced6 selon invention peut egalement 
Stre tout routeur plac6 au niveau d'un point de congestion dans le r6seau (en particulier 
pour tout acces k un lien ADSL). 

On pr6sente maintenant, en relation avec la figure 2, un mode de realisation 
particulier du proc6d6 selon invention. II permet de prot6ger les informations 
importantes des rafales et apporter des solutions k Tantinomie entre Toptimisation d'un 
flux video contenant des rafales et le lissage des rafales pour un transport de qualite dans 
le r6seau. 

Dans ce mode de r6alisation particulier du proc6d6 selon Tinvention, le 
m6canisme d' ensemble forme un « conditionneur de trafic d6centralis6 multi-couche » 
appele «MLDTC » (pour « Multi-Layers Decentralized Traffic Conditioner »). II est 
constitu6 de deux f onctions execut6es s6quentiellement : 

- la premiere est appelee « MLTR » (pour « Multi-Layers Traffic Regulator ») 
du fait qu'elle forme un « regulateur de trafic multi-couche ». Elle assure le 
controle de rafales par niveau hidrarchique. Elle est basee sur la mise en 
oeuvre d'un seau a jetons k N niveaux de fonctionnement (reference 30), avec 
N buffers (m6moires-tampons) de jetons virtuels. Chaque buffer de jetons 
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correspond k un niveau hierarchique. Chaque niveau de fonctionnement est 
d6fini par un jeu de paramfetres (voir discussion ddtaillee ci-apres). La 
fonction MLTR assure T attribution de jetons en fonction de la priority du 
paquet entrant et de la ressource disponible dans le buffer de jetons 
5 correspondant. Dans Texemple de la figure 2, on a N = 3 et la representation 

de trois seaux indique uniquement la distinction des trois jeux de param^tres 
(il n'y a en realite qu'un seul seau k trois niveaux de fonctionnement) ; 
- la seconde est appelee « TBTS » (pour « Token Bucket Traffic Shaper ») du 
fait qu'elle est basee sur un algorithme de type seau a jetons k niveau unique 

10 (« Token Bucket ») (reference 31) et execute un lissage du trafic pour un 

ecoulement regulier sur le reseau en limitant le d6bit instantane a une valeur 
acceptable par le r6seau. La memoire tampon de la fonction TBTS est de 
capacite raisonnable pour garantir un cout moindre des systemes et un temps 
de transfert limite dans la fourniture de Tinformation k Tusager. La 

15 contrepartie de la taille finie est la limitation des rafales asccepttes en entrfe 

du reseau. 

La fonction MLTR est adapt6e k Tacceptation diff6renti6e des rafales en fonction 
du niveau de priority. Elle s' applique aux paquets DP (r6f6renc6s 20 k 26 sui la figure 2) 
dont le champ DSCP (« Differentiated Services Code point ») est marqu6 soit par la 

20 source, soit par un systfeme de classification. Chaque niveau de priority i dispose de ses 

propres paramdtres, pour un tampon unique, commun aux 3 niveaux, mais avec des 
niveaux d'acceptation des paquets de donn^es variables. Ce mecanisme r6pond aux 
attentes d'un signal video, car il ne traite pas uniform6ment toutes les informations. En 
effet, on rappelle qu*un codage MPEG aboutit k plusieurs niveaux d'informations qu'il 

25 convient de traiter diff6remment selon leur importance. L'objectif est de favoriser les 

rafales d'un niveau i par rapport k un niveau j, dont les informations sont moins 
importantes (j > i). Les paquets relatifs au niveau i ont alors la priorite pour exploiter les 
ressources disponibles. 

GrSce k la fonction TBTS, le mdme d6bit moyen est obtenu pour des tailles de 

30 rafales difKrentes, et tenant compte de Tintervalle les separant. Un tel mecanisme est 
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bien adapt6 aux rafales des flux video, qui sont variables, en raison de la grande 
diversit6 des contenus transportes (sports, actualit6s, paysages, 

On presente maintenant de fa9on detaill6e un exemple de realisation de la 
fonction MLTR, qui assure la regulation et le contrSle de rafales. Dans la suite de la 
description, on etudie k titre d'exemple le cas oil cette fonction MLTR est basee sur un 
seau a jetons h trois niveaux de fonctionnement (N = 3). 

Comme illustr6 sur la figure 3, chaque niveau de fonctionnement i du seau k 
jetons k trois niveaux de fonctionnement 30 est gere par un r^jgulateur h^(x,, bmO, i G {1, 
2, 3}, avec : 

- Ti le debit nominal de ce regulateur ; 

- bm^ la taille maximale du buffer de jetons de ce regulateur ; 

- bi(t) la valeur instantanee du remplissage du buffer de jetons de ce regulateur. 
La taille du buffer de jetons (hd impose une taille maximale pour les rafales pour 

chaque niveau. La tolerance d'un regulateur de niveau i vis-^-vis des rafales de grande 
taille depend de la taille du buffer de jetons b^ et du d6bit ri. 

Les paquets conformes (c'est-a-dire ceux ^ qui il a pu etre attribue des jetons par 
le seau multi-niveau 30) sont plac6s dans un buffer de paquets k 6mettre 28, qui forme 
un moyen de gestion d'une file d'attente. Si un nombre insuffisant de jetons est 
disponible dans le seau multi-niveau, les paquets sont alors consid6r6s comme non- 
conformes et sont 61inun6s. lis sont jetds dans la poubelle r6f6rencee 27. Une autre 
option est de transmettre ces paquets avec une priorit6 plus faible. Cependant, le 
nouveau marquage des paquets pour leur attribuer ime priority plus faible augmente la 
probability de rejet de paquets dans les noeuds congestionn6s. 

Pour favoriser les rafales des niveaux les plus prioritaires, les trois buffers de 
jetons, bl, b2 et b3 sont partag6s entre les diffdrents niveaux. En d'autres termes, un 
paquet de niveau de priority i pent se voir attribuer des jetons d'un buffer de jetons 
associ6 k un niveau de priority j moins prioritaire (j > i) lorsque les jetons disponibles 
dans le buffer de jetons de niveau de priorite i ne sont pas suffisants. 

Cependant, k cause de ce principe d'emprunt, les paquets de niveau i risquent 
d'utiliser toutes les ressources en jetons des niveaux moins prioritaires j. Ceci peut 
emp6cher de garantir le d6bit nominal au niveau j au profit du niveau i. Comme illustre 
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sur la figure 3, la solution est de limiter cet emprunt par un parametre Kj, propre au 
niveau j, et dont Tobjectif est de prot6ger ce dernier des niveaux plus prioritaires en 
garantissant une quantity de ressources (jetons) r&ervdes exclusivement aux paquets de 
niveau j. Par cons6quent, le parametre Kj garantit un seuil de remplissage des buffers de 
jetons au-dessous duquel les paquets d'un niveau plus prioritaire ne peuvent plus se 
servir, Le parametre du regulateur de niveau j est illustr6 sur la figure 3. 
La valeur de Kj doit 6tre choisie telle que bmj ^ K, ^ MTU, 
Ceci revient h garantir pour les paquets de niveau j le d6bit nominal et des rafales 
limit6es par K,. Le cas particulier oil Kj est adapt6 k la taille utile d'un paquet sur le 
reseau (MTU (« Maximum Transfer Unit », c'est-^-dire « taille maximale d'une unit6 
el6mentaire de transfert ») pour un reseau IP) correspond h une garantie du d6bit 
nominal Tj pour le niveau j mais sans garantie de rafales. Les ressources en jetons 
pourraient etre utilisees par les niveaux plus prioritaires. 

Les trois jeux de paramfetres definissant les trois niveaux de fonctionnement du 
seau jetons multi-niveau peuvent etre d6crits : 

- soit par une representation de trois buffers ind^pendants, avec un usage 
partag^ des ressources entre les trois niveaux ; 

- soit par une representation cumul6e des ressources faisant mieux ressortir les 
priorites entre les niveaux et les interd6pendances de fonctionnement 
provenant du partage des ressources. 

Toutefois, ces representations sont identiques dans leur fonctionnement 

On pr6sente maintenant, en relation avec la figure 4, une description du 

fonctionnement du seau h jetons multi-niveau avec des buffers (memoires-tampons) 

independants. 

Le rechargement des buffers de jetons est calcuie pour chacun des trois niveaux 
au moment de rarriv6e d'un nouveau paquet, en fonction du temps le s6parant du paquet 
precedent. 

bXt + T)^ min[(Z?, (f)+ r, .t) bm, ] 
^ ^2(^ + ^)= niin[(Z?2(0+^2-7^)^'«2] (Equation 1) 

63 (f + r)=: min[(63 (f )+ h T\bm^ ] 
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SI 



La prise en compte du paquet airivant de niveau i at de taille Pi est obtenue par 
ralgorithme suivant : (mode paquets) 

si(F[ ^ )=> = fei - ; envoi; 
autre : si{P^ ^ (i^ - ))=> b^^h- Px \ envoi; 
autre : 5i(Pi ^ (63 - = b^ -P^\envoi\ 
autre : perte; 

si(jP2 ^ b2 )=> 62 ^2 ^ A J envoi; 

autre : ^/(Pj ^ (^^3 - ^3 ))^ ^3 = - ^2 J e«voz; (Equation 2) 

au^e : perte; 

'siil\ ^ 63 )=*> 63 = 63 - P^;envoi; 
autre : perte; 



siiP^y 



La figure 4 est une repr6sentation graphique de cet algorithme d* attribution de 
5 jetons dans le cas ou le fonctionnement du seau a jetons multi-niveau est d6crit avec des 

buffers ind6pendants. EUe montre Tusage possible des ressources b^, et bj pour 
chacun des niveaux. Les traits 6pais (r€f6renc6s 41, 42 et 43) montrent le remplissage 
des buffers de jetons (c'est-?l-dire le nombre de jetons disponibles) pour chacun des 
niveaux, et les filches les ressources (c'est-Ji-dire les jetons) prises par les paquets 
10 entrants (PI , P2 ou P3) selon leur priorite. 

On pr6sente maintenant, en relation avec la figure 5, une description du 
fonctionnement du seau jetons multi-niveau avec des buffers correles. 

Le fonctioimement avec trois r6gulateurs ind^pendants b^ir^^bm^), i G {1, 2, 3}, 
est Equivalent au fonctionnement avec trois r6gulateurs d6pendants B^{R^yBM^) avec : 
15 - Bt(f) la valeur instantande du remplissage du buffer de jetons virtuel relatif 

aux paquets de niveau i ; 
- BMf la taille maximale du buffer de jetons virtuel relatif aux paquets de 
niveau i. 

Les tailles de buffers de jetons par niveau sont obtenus par : 
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10 



53=63 

^2 = + 63 (Equation 3) 

Ce mode implique que : 51 s 52 a 53 

Le rechargement des buffers de jetons peut alors s'exprimer sous une forme 
gquivalente k Equation 1 par : 

5, {t + t)= min[(ii (0+ T),bm, > minK^^ (0+ r^^)>bm^ ^ minfe (0+ hT^bm^ ] 
53 + r ) = min [(63 (r ) + T ) fe/nj ] 

(Equation 4) 

Si on suppose que min[(feXO+ n-r)fcmj- ^/•T' » (Equation 4) devient : 

5^ + (0+ ^3 (0+ O2 + ^3 )7' 

53(^ + 7^)«^3(0+'3r 



La figure 5 est une representation graphique de ralgorithme d' attribution de 
jetons dans le cas oil le fonctionnement du seau ^ jetons multi-niveau est decrit avec des 
buffers corr^l6s. EUe montre Tusage possible des ressources Bi, B2 et B3 pour chacun 

15 des niveaux. De mSme que sur la figure 4, les traits 6pais (r6f6renc6s 51, 52 et 53) 

montrent le remplissage des buffers de jetons (c'est-k-dire le nombre de jetons 
disponibles) pour chacun des niveaux, et les flfeches les ressources (c*est-k-dire les 
jetons) prises par les paquets entrants (PI , P2 ou P3) selon leur priority. 

Si les Equations du rechargement traduisent exactement le mSme comportement 

20 pour les deux approches, le choix de Tattribution des jetons aux paquets a Tarrivfe peut 

se r6aliser par deux alternatives : 

- en mode discontinu (paquets): un paquet ne peut se servir que d'un seul 
r6gulateur ; 

- en mode continu (bits): un paquet peut se servir de plusieurs r6gulateurs k la 
25 fois. 
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Selon le fonctionnement en mode discontinu (paquets), la prise en compte de 
rairiv6e du paquet est obtenue par ralgoritiime suivant : 



autre :si\ 



autre : si(l\ ^ (s, - K3 )) 



■,envoiy 



autre : perte; 
siiP^^B^-B,) 



(B,^B,-P, 
\B,^B,-P,' 

autre : ^(Pj ^ (S3 - ^3 ))=> • 
autre : perte; 



;envoi; 



B3 =£3 -P2 
B2 =B2 - Piienvoi; 
B,^B,-P2 



sKP,) 



si{P3^B,)=> 
autre : perte; 



Bj -P^ 

B2 =B2 -P3; envoi; 

B,=B,-P, 



(Equation 5) 



5 II est a noter que (Equation 2) et (Equation 5) sont 6quivalentes. 

Dans ce mode de fonctionnement discontinu (paquets), un paquet est servi par 
les ressources du niveau correspondant au paquet (niveau i) ou d'un niveau moins 
prioritaire (niveau j), II est a noter que ce fonctionnement n'est pas optimal, car un 
paquet entrant est rejet6 m8me si la somme des ressources disponibles r^parties sur les 3 
10 niveaux est suffisante. 

Selon le fonctionnement en mode continu (bits), la prise en compte de Tarrivde 
du paquet est obtenue par Talgorithme suivant : 
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51 



5i(p, s £>, )=*• 6, = 6i - P; envoi; 
autre : «((P, - + (fe^ - (i>3 - K, ))=> . 



b^=K2 ;envoi; 
bi =0 



a«frc : perte; 

si(F2 & b^ )=*► bi=b^- P^ienvoi; 
autre : si{R s {b, - H=> -! ~ ^ ^^;envoi; 



i 



autre : perte; 



\ autre: perte; 



A priori ce mode de fonctionnement continu (bits) est plus optimal que le mode 
discontinu (paquets). En effet, il pemiet une utilisation maximale de ressources propres 
du niveau avant de demander des ressources k un niveau moins prioritaire. 
5 On pr6sente maintenant de fa9on d6taill6e un exemple de realisation de la 

fonction TBTS qui assure la mise en forme du trafic. 

Le seau a jetons k niveau unique 31, sur lequel est bas6 cette fonction TBTS, est 
par exemple d6fini par les param^tres suivants : 

- R, le d6bit moyen ; 

10 - R„ax» 1© d^bit maximal a la sortie ; 

- B(t), la valeur instantande du remplissage du buffer de jetons (B^^x ©st la 
. taille maximale du buffer de jetons) ; 

- S, la valeur instantan^e du remplissage du buffer de paquets 28 (S^a^ est la 
taille maximale du buffer de paquets 28) ; 
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- T, le temps s6parant Tairivee de deux paquets consecutifs ; 

- T, la duree d'une rafale de paquets. 

Les paquets conformes (c'est-St-dire ceux k qui il a pu Stre attribu6 des jetons par 



le seau k niveau unique 31) sont transmis alors que les paquets non-conformes sont 
retard6s dans le buffer de paquets 28 pour les contenir dans Tenveloppe de trafic cibl6. 
La taille du buffer de paquets 28 est k manipuler avec precaution car elle peut induire un 
d61ai suppl6mentaire, qui doit rester raisonnable. 

Le fonctionnement du seau k niveau unique 31 (et done de la fonction TBTS) 
peut etre d6crit par les equations suivantes : 



Si on considfere r^^^x' 1® d6bit maximal k la sortie de la fonction MLTR, 
revolution du remplissage du buffer de paquets 28 entre Tarrivee de deux paquets 
consecutifs peut etre decrit par requation suivante : 



B{t + r)« min[(5(0+ RT} ] 




s(f + t)^ s{ty ^(rr^-Ryr 

et SityRJ-B^^^S{t^T)^Sit)+{r^-R)T 
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REVENDICATIONS 

1. Proc6d6 de contrdle d*un trafic de paquets de donnees en entree d'un reseau, le 
trafic comprenant N flux et/ou sous-flux associ6s chacun h un niveau de priorite, N ^ 2, 
chacun des paquets 6tant marque avec le niveau de priority associe au flux ou sous-flux 
auquel appartient ledit paquet, 

caract6ris6 en ce qu*il comprend une dtape de mise en oeuvre d'un ni6canisme de seau k 
jetons k N niveaux de fonctionnement avec N m6moires-tampons de jetons contenant 
chacune un nombre de jetons disponibles, les jetons de chacune des N m^moires- 
tampons de jetons etant utilises pour traiter Tun des N niveaux de priority, chacun des 
paquets 6tant accept^ ou refuse selon qu'il est possible ou non de lui attribuer des jetons 
en fonction des jetons disponibles au moins dans la m6moire-tampon de jetons utilisee 
pour traiter le niveau de priorite dudit paquet. 

2. Proc6d6 selon la revendication 1, caract6rise en ce que le trafic comprend N 
sous-flux correspondant chacun a un des N niveaux hierarchiques d'un flux hierarchique 
ou d'un agr6gat de flux hi&archiques. 

3. Proced6 selon la revendication 1, caracteris6 en ce que le trafic comprend N 
sous-flux correspondant chacun k un des N types d'images d'un flux multimedia ou d'un 
agr6gat de flux multimedia. 

4. Proc6d6 selon la revendication 1, caract6ris6 en ce que le trafic compiend N flux 
correspondant chacun k un des flux d'un multiplex d'au moins deux flux. 

5. Proc6d6 selon Tune quelconque des revendications Ik 4, caract6ris6 en ce que le 
trafic comprend N flux et/ou sous-flux appartenant k une mSme classe de service. 

6. Proc6d6 selon Tune quelconque des revendications I kS, caract6ris6 en ce que 
les paquets refus6s sont jet6s. 

7. Proc6d6 selon Tune quelconque des revendications 1^6, caract6ris6 en ce que le 
r6seau est de type DP ou Equivalent. 

8. Proc6dd selon Tune quelconque des revendications 1 k 7. caracterise en ce que 
chacun des N niveaux de fonctionnement du m6canisme de seau k jetons est g6re par un 
r6gulateur bjCrj, bmi), i G {1 ^ N}, avec : 

r, le debit nominal du regulateur ; 

bmi la taille maximale de la memoire-tampon de jetons du regulateur ; 
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bj(t) la valeur instantante du remplissage de la ni6moire-tanipon de jetons du 
i6gulateur. 

9. Precede selon Tune quelconque des revendications 1^8, caract6ris6 en ce que 
les jetons des N m6moires-tampons de jetons sont partages entre les N niveaux de 
priority, un paquet de niveau de priority i pouvant se voir attribuer des jetons d'une 
memoire-tampon de jetons associee k un niveau de priority j moins prioritaire lorsque les 
jetons disponibles dans la m6moire-tampon de jetons de niveau de priority i ne sont pas 
suffisants. 

10. Precede selon la revendication 9, caract6ris6 en ce que, pour chaque niveau de 
priorite hormis le niveau de priorite le plus prioritaire, on garantit une quantity de jetons 
(Kj) reserves exclusivement aux paquets possedant ledit niveau de priorite. 

11. Proc6d6 selon Tune quelconque des revendications 9 et 10, caracteris6 en ce que 
r attribution de jetons a un paquet de niveau de priorite i est effectuee selon un mode 
discontinu par paquet et consiste h attribuer : 

soit des jetons disponibles dans la m6moire-tanipon de jetons de niveau de 
priority i ; 

^ soit des jetons disponibles dans une memoire-tampon de jetons de niveau de 
priority j moins prioritaire, lorsque les jetons disponibles dans la memoire- 
tampon de jetons de niveau de priorit6 i ne sont pas suffisants. 

12. Proc6d6 selon Tune quelconque des revendications 9 et 10, caracteris^ en ce que 
Tattribution de jetons k un paquet de niveau de priorit6 i est effectu6e selon un mode 
continu par bit et consiste h, attribuer : 

des jetons disponibles dans la memoire-tampon de jetons de niveau de priority i ; 
et en complement des jetons disponibles dans au moins une m6moire-tampon de 
jetons de niveau de priorite j moins prioritaire, lorsque les jetons disponibles 
dans la m6moire-tampon de jetons de niveau de priority i ne sont pas suffisants. 

13. Proced6 selon Tune quelconque des revendications 1 i 12, caract6ris6 en ce que 
les paquets accept6s par le mecanisme de seau a jetons k N niveaux de fonctionnement 
sont places dans une file d'attente, 

et en ce que ledit proc6d6 comprend en outre une 6tape de mise en oeuvre d'un 
m6canisme de seau k jetons a un seul niveau de fonctionnement avec une unique 
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memoire-tampon de jetons, de fa9on k prendre les paquets contenus dans la file d'attente 
et les envoyer sur le reseau en executant un lissage du trafic par limitation du d6bit 
instantan6 k une valeur acceptable par le r6seau. 

14. Programme d'ordinateur, caract6ris6 en ce qu*il comprend des instructions de 
5 code de progranune pour Tex^cution des etapes du proc6d6 selon Tune quelconque des 

revendications 1 & 3, lorsque ledit programme est ex^ut6 sur un ordinateur. 

15. Dispositif de controle d'un trafic de paquets de donndes en entr6e d'un rdseau, le 
trafic comprenant N flux et/ou sous-flux associes chacun k un niveau de priorite, N 2: 2, 
chacun des paquets etant marque avec le niveau de priorite associe au flux ou sous-flux 

10 auquel appartient ledit paquet, 

caract6ris6 en ce qu'U comprend des moyens de mise en oeuvre d'un mecanisme de seau 
k jetons k N niveaux de fonctionnement avec N memoires-tampons de jetons contenant 
chacune un nombre de jetons disponibles, les jetons de chacune des N memoires- 
tampons de jetons etant utilises pour traiter Tun des N niveaux de priority, chacun des 

15 paquets etant accepte ou refus6 selon qu'il est possible ou non de lui attribuer des jetons 

en fonction des jetons disponibles au moins dans la memoire-tampon de jetons utilis6e 
pour traiter le niveau de priority dudit paquet. 

16. Dispositif selon la revendication 15, caract6ris6 en ce qu'il comprend des 
moyens de partage des jetons des N m6moires-tampons de jetons entre les N niveaux de 

20 priority, un paquet de niveau de priority i pouvant se voir attribuer des jetons d'une 

m6moire-tampon de jetons associde a un niveau de priority j moins prioritaire lorsque les 
jetons disponibles dans la memoire-tampon de jetons de niveau de priority i he sont pas 
suffisants. 

17. Dispositif selon la revendication 16, caract6ris6 en ce que, pour chaque niveau de 
25 priority hormis le niveau de priority le plus prioritaire, lesdits moyens de partage 

comprennent des moyens de garantie d'une quantity de jetons (Kj) reserves 
exclusivement aux paquets possedant ledit niveau de priorite. 

18. Equipement reseau comprenant un dispositif de controle selon Tune quelconque 
des revendications 15 k 17 j caract6rise en ce que ledit 6quipement reseau appartient au 

30 groupe comprenant : 
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des 6quipeinents r&eau situ6s entre un reseau d'un foumisseur d'application ou 
de service et un r6seau d'un foumisseur d'un service reseau, constituant ledit 
reseau en entrde duquel est effectue le controle d*un trafic de paquets de 
donndes ; 

des routeurs compris dans des noeuds d'un reseau d'un foumisseur d'un service 
r6seau, constituant ledit r6seau en entree duquel est effectu6 le contr61e d*un 
trafic de paquets de doimees. 
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